The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. Similarly, unless otherwise indicated, it should not be assumed that a problem has been recognized by the prior art merely because the problem is discussed in this section.
The ability to store and retrieve large amounts of data is one of the most important functions of computers in today's society. To carry out these functions, database systems are typically used to retrieve and store data in databases. Database systems have performed these functions very successfully, creating for society the ability to retrieve data at speeds and quantities previously unimagined, and bestowing onto society an unprecedented level of access to information. The success of database systems has unleashed an insatiable demand for even faster and more efficient database systems that process even greater quantities of data.
It is often desirable to transport (or move) a database from one platform to another. As used herein, the term ‘platform’ refers to a computer system running a particular database product version and operating system product. A computer running Oracle's 10 g database server product for UNIX is a different platform than a computer running Oracle's 10 g database server product for Windows NT. An Oracle 10 g tablespace created on UNIX would have a different on-disk format than the same tablespace created on Windows NT.
With the emergence and maturity of new platforms, many database operators wish to transport an existing database to a new platform. Also, it may be desirable to transport a database to a lower cost platform, or to a new platform for purposes of replication, instantiation, and/or migration.
According to one approach for transporting a database from a source platform to a target platform, a new database is created on the target platform, and the new database is populated with data from the source database. To populate the new database with data from the source database, utilities such as export/import or datapump are used. A conventional technique for implementing the export/import operations is the command generation technique. Under the command generation technique, an “exporting” database system generates a file of insert commands. The insert commands conform to a database language, such as the structured query language (“SQL”). For each record being exported, an insert command specifies the creation of a record with the values needed to generate a copy of the record being exported. To import the data, an “importing” database system, which is capable of executing commands written in the database language, scans the file, executing each insert command.
However, export/import or datapump operations are very slow since they need to process the data one row-at-a-time. Executing an insert command for each record being exported is typically a slow process, which may span days for larger databases as a result of processing the data one row-at-a-time. While data is being exported, access to the data is restricted, and users may need to tolerate a lengthy downtime. Consequently, the database user, who requires access to the data, may be significantly impacted while data is being exported. Similarly, data dump operations also rely on processing the data logically one row-at-a-time. In some cases, export/import and data dump operations are too slow to meet user needs, and the associated traditional export and/or dump files require a large amount of storage space. Thus, conventional techniques for exporting data may be significantly burdensome.
Another approach for moving data from a source database to a target database involves the use of transportable tablespaces. A tablespace is a logical collection of database objects that reside in physical storage containers (e.g., data files). Database objects are objects managed by a database system. Transportable tablespaces are tablespaces that can be copied and integrated into another database system, or in other words, attached (e.g., “plugged in”) to the other database system. Transportable tablespaces are described in U.S. Pat. No. 6,549,901. With respect to a tablespace, database, and database server, the term “attach” refers to configuring a database and/or database server so that the database objects in the tablespace are incorporated within the database and the tablespace is used to store data for the database.
In contrast to repopulating the data at the row level, configuring a database to attach a tablespace involves (1) modifying database metadata so that the tablespace and database objects associated with the tablespace are defined to be part of the database and (2) incorporating storage containers into the database for holding the database objects. The database metadata may be altered using a variety of techniques involving automated steps and/or manual steps performed by a Database Administrator (DBA). The DBA can run utilities available on the source database system that may be executed to export the metadata into a “metadata dump file”, and run utilities on the target database system to construct metadata from the metadata dump file. Alternatively, metadata can be included with the data being transported in the tablespace, and the target database can reconstruct the metadata from the metadata included in the tablespace. The DBA can also manually reconstruct the metadata on the target database system. Using the process of attaching tablespaces allows data to be copied using operating system utilities for copying files, which copy the physical bits and run much faster than the process of extracting and loading data by executing queries and insert statements.
However, while the approach of transportable tablespaces advantageously increases the speed and ease of transferring data from a source database to a target database, transportable tablespaces cannot be used to transfer the entire contents of a source database to a target database because transportable tablespaces cannot transfer certain types of metadata (such as undo information and redo information) stored in the database. For example, system tablespaces cannot be transported from a source database to a target database using transportable tablespaces because certain types of metadata (such as the SYSTEM rollback segment) cannot be transferred using transportable tablespaces.
In view of the foregoing, there is a need for a more efficient approach for transferring information in a database on a source platform to a database on a target platform.